| Part of a series on: |
| Video game graphics |
|---|
|
Lists
|
A virtual camera system aims at controlling a camera or a set of cameras to display a view of a 3D virtual world. Camera systems are used in videogames where their purpose is to show the action at the best possible angle; more generally, they are used in 3D virtual worlds when a third person view is required.
As opposed to film makers, virtual camera system creators have to deal with a world that is interactive and unpredictable. It is not possible to know where the player's character is going to be in the next few seconds; therefore, it is not possible to plan the shots as a film maker would do. To solve this issue, the system relies on certain rules or artificial intelligence to select the most appropriate shots.
There are mainly three types of camera systems. In fixed camera systems, the camera does not move at all and the system displays the player's character in a succession of still shots. Tracking cameras, on the other hand, follow the character's movements. Finally, interactive camera systems are partially automated and allow the player to directly change the view. To implement camera systems, video game developers use techniques such as constraint solvers, artificial intelligence scripts, or autonomous agents.
Contents |
In video games, "third person" refers to a graphical perspective rendered from a fixed distance behind and slightly above the player character. This viewpoint allows players to see a more strongly characterized avatar, and is most common in action games and action adventure games. Games with this perspective often make use of positional audio, which the volume of ambient sounds varies depending on the position of the avatar.[1]
There are primarily three types of third-person camera systems: the "fixed camera systems" in which the camera positions are set during the game creation; the "tracking camera systems" in which the camera simply follows the player's character; and the "interactive camera systems" that are under the player's control.
In this kind of system, the developers set the properties of the camera, such as its position, orientation or field of view, during the game creation. The camera views will not change dynamically, so the same place will always be shown under the same set of views. An early example of this kind of camera system can be seen in Alone in the Dark. While the characters are in 3D, the background on which they evolve has been pre-rendered. The early Resident Evil games are notable examples of games that use fixed cameras.
One advantage of this camera system is that it allows the game designers to use the language of film. Indeed, like filmmakers, they have the possibility to create a mood through camerawork and careful selection of shots. Games that use this kind of technique are often praised for their cinematic qualities.[2]
As the name says, a tracking camera follows the characters from behind. The player does not control the camera in any way - he/she cannot for example rotate it or move it to a different position. This type of camera system was very common in early 3D games such as Crash Bandicoot or Tomb Raider since it is very simple to implement. However, there are a number of issues with it. In particular, if the current view is not suitable (either because it is occluded by an object, or because it is not showing what the player is interested in), it cannot be changed since the player does not control the camera.[3][4][5] Sometimes this viewpoint causes difficulty when a character turns or stands face out against a wall. The camera may jerk or end up in awkward positions.[1]
There is a large body of research on how to implement a camera system[6] . The role of a constraint solver software is to generate the best possible shot given a set of visual constraints. In other words, the constraint solver is given a requested shot composition such as "show this character and ensure that he covers at least 30 percent of the screen space". The solver will then use various methods to try creating a shot that would satisfy this request. Once a suitable shot is found, the solver outputs the coordinates and rotation of the camera, which can then be used by the graphic engine renderer to display the view.[7]
In some camera systems, if no solution can be found, constraints are relaxed. For example, if the solver cannot generate a shot where the character occupies 30 percent of the screen space, it might ignore the screen space constraint and simply ensure that the character is visible at all.[8] Such methods include zooming out.
Some camera systems use predefined scripts to decide how to select the current shot. Typically, the script is going to be triggered as a result of an action. For instance, when the player's character initiates a conversation with another character, the "conversation" script is going to be triggered. This script will contain instructions on how to "shoot" a two-character conversation. Thus the shots will be a combination of, for instance, over the shoulder shots and close-up shots. Such script-based approaches usually rely on a constraint solver to generate the camera coordinates.[9]
Bill Tomlinson used a more original approach to the problem. He devised a system in which the camera is an autonomous agent with its own personality. The style of the shots and their rhythm will be affected by its mood. Thus a happy camera will "cut more frequently, spend more time in close-up shots, move with a bouncy, swooping motion, and brightly illuminate the scene".[10]
In 2010, the Kinect was released by Microsoft as a 3D scanner/webcam hybrid peripheral device which provides full-body detection of Xbox 360 players and hands-free control of the user interfaces of video games and other software on the console. This was later modified by Oliver Kreylos[11] of University of California, Davis in a series of YouTube videos which showed him combining the Kinect with a PC-based virtual camera[12]. Because the Kinect is capable of detecting a full range of depth (through computer stereo vision and Structured light) within a captured scene, Kreylos demonstrated the capacity of the Kinect and the virtual camera to allow free-viewpoint navigation of the range of depth, although the camera could only allow a video capture of the scene as shown to the front of the Kinect, resulting in fields of black, empty space where the camera was unable to capture video within the field of depth. Later, Kreylos demonstrated a further elaboration on the modification by combining the video streams of two Kinects in order to further enhance the video capture within the view of the virtual camera[13]. Kreylos' developments using the Kinect were covered among the works of others in the Kinect hacking and homebrew community in a New York Times article[14].